[書籍レポート] 「オブザーバビリティ・エンジニアリング」はパワーワード満載の「『入門 監視』の次に読むべき本」だった

はじめに

今年(2023年)の1月末に発売されたこちらの本、もう読まれたという方も多いのではないでしょうか！（挨拶

本記事は、まだ読まれていない、買ってもいないという方に向けて、「紹介しなきゃ」という謎の強い使命感をもって書かれています。

というのも、実は本記事の執筆者（ぼくです）は、300ページを越えるこの本のまだ半分ほどしか読むことが出来ていません。。！ ^*1

それでもこの本を紹介するモチベーションは十分です。なにしろ、この本は冒頭から、もっといえば「まえがき」の段階から、パワーワードにあふれた一冊だからです。引用してみましょう。

“（「オブザーバビリティ」という）用語が注目されるようになると、ある種の隣接性を共有する別の用語と互換的に使われる（残念ながら、避けられない）運命に見舞われました。「モニタリング」です。
モニタリングツールやベンダーは、オブザーバビリティの哲学的、技術的、社会技術的基盤をモニタリングと区別しようとする人たちが使っていたのと同じ言葉や語彙を使い始めたのです。このような混同は、控えめに言っても、特に有益なものではありませんでした。それは、「オブザーバビリティ」と「モニタリング」を同一概念に混同してしまう危険性があり、その結果、その違いについて意味のあるニュアンスの会話をすることがより一層難しくなってしまうからです。”
（「まえがき」より / 引用内強調は引用者による・以下同様）

　

（しばらくお待ちください）

　

...OK、複数の監視ツールを商材として扱う会社の社員としてはちょっと刺激が強すぎる引用です。

実はこのあと、もっと刺激的な言説が続くのですが、その部分はちょっとご勘弁ください。しかしながらここだけでも、この本が「見過ごされがちな、かつ非常に重要な事象」について言及しつつ、「各処に配慮した現状追認的な日和見主義」とは対極にある、というところは分かって頂けたのではないでしょうか。
しかもそのような内容が、この本には、確固たる理念と具体性を伴いつつ大量に盛り込まれています。 ^*2

もう少し引用してみると、以下のような具合です。

“ソフトウェアシステムの「オブザーバビリティ」とは、システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です”
（「1.2　オブザーバビリティのソフトウェアシステムへの適用」より）

“チームにもっとも長く在籍しているエンジニアが、チーム最高のデバッガーであり、最後の砦のデバッガーとなることが多いのです。デバッグが、以前から知られていたパターンを解読した経験に基づいて行われるのであれば、このような傾向は当然と言えるでしょう。逆に、オブザーバビリティを実践しているチームは、根本的に違う方向に傾きます。オブザーバビリティツールでは、チーム内の最高のデバッガーは、通常、もっとも好奇心の強いエンジニアです。"
（「2.2　オブザーバビリティがより良いデバッグを可能にする理由」より）

“経験豊富な運用エンジニアリングチームは、すべての「正しい選択」を行っていました。 しかし、私たちが知っているベストプラクティスは旧来のアプローチから生まれたものであり、分散型マイクロサービス時代の問題解決に対応しきれないという事実を発見しつつありました。”
（「3.2　Parseでのスケーリング」より）

“手順書やダッシュボードの作成に費やされた時間は、ほとんど無駄になってしまいます。 なぜなら現代のシステムでは、まったく同じ方法で2度故障することはほとんどないからです。”
（「8章　オブザーバビリティを実現するためのイベント解析」より）

この調子で引用を続けたらどれだけ長くなるか分からない ^*3のですが、ぼくが読んだ中でハイライトした全ての文章を引用はできないので、最後にこれだけ引用させてください。

"私がハワイに新婚旅行に行っていたときのこと、午前3時にMongoDBがParse APIサービスをダウンさせたということで呼び出されたのを覚えています。 私の上司はCTOだったのですが、相当な勢いで謝ってきました。 しかし、サイトはダウンしていたのです。 1時間以上もダウンしたままで、誰もその原因を突き止められませんでした。 そこで彼らは、私に電話をかけてきたのです。 そう、私は文句を言いました。 でも、心の底では、密かにすごいと思っていたんです。 私は「必要とされていた」のです。私は特別な存在だったのです。
プロダクトマネジメントを任されたことがある人は、このパターンに見覚えがあるかもしれません。 ヒーロー文化はひどいものです。 会社にとっても良くない。 ヒーローにとっても良くない（燃え尽き症候群になる）。 後から来たエンジニアは、シニアエンジニアが辞めない限り「最高の」デバッガーになるチャンスはないと感じて、ひどく落胆します。 このパターンは完全に不要です。 しかし、もっとも重要なことは、それが「スケールしない」ことです。”
（「3.5　Parseにおけるプラクティスの変革」より）

いかがでしょう、ぼくにとっては耳が痛い、いくら「属人化はヨクナイ」と唱えていてもその本質を本当に理解していたか、自問せざるを得ない言葉でした。
アイキャッチふくめ画像にいくつか含めておきましたので、気になる方は是非拡大して読んでみて下さい！

どのようなひとにお勧めの本か？

では以上を踏まえて、どのような方にお勧めかという話を少し。

この本は、絶対的な価格としてはお安い本ではありませんが、その価値は十分すぎるほどと思います。それでも「読む価値あるかなぁ」と思われる方々も多いと思うので、少し自分なりにまとめてみました。

1. ここまでの引用を読んで、何かしら心の琴線に触れた方

これはもう、間違いなく全員が対象となると思います。多くは語りません。

2. 訳者の「山口 能迪」氏のお名前に「おっ」と思われた方

こちらも間違いないでしょう ^*4。ぼくはこのパターンでした。

Googleの山口氏と言えば、記憶に新しいところでは「SREの探求」の監訳を務められた方ですし、そもそも日本において「オブザーバビリティ」という言葉の啓蒙に初期から尽力されてきた方ですね。
共著の大谷氏もこの分野で高い実績をあげてらっしゃる方です。内容に間違いは無いと思っていいでしょう。 ^*5

3. DevOpsに則って開発・運用を行われている開発者

ぼくがこの業界にはいった当時（20年以上前） ^*6から「アラートが鳴ったら最終的には開発者が呼び出される」という状態でした。いまは確かに別の用語が使われたり道具が揃ったりしていますが、本質的なところは現在でも何も変わっていないし、むしろDevOpsの原則のもとでいえば、アプリケーションの運用・監視は間違いなく開発者の担当です。 ^*7

その前提でお話しすれば、本書籍のターゲットは間違いなく「開発者」です。実際にサービスを提供するために動作しているアプリケーションの面倒を真に見るべき方々です。本書は現役で「アプリケーションの開発・運用をされている方」が手がけられているので、様々な気付きを与えてくれるものと思います。
もし「これまであまり意識してこなかった」「監視完全に理解してる　←」「雰囲気でやってる」という方がいたら、是非この機会に手に取って頂ければと思います。

4. SREs

さらに。
今さらいうまでもなく、インフラとアプリケーションの両方に気を配るべき「SRE」にとって、オブザーバビリティは欠かせない概念です。

この本にはただの啓蒙・概念的な情報だけでなく、かなり具体性をもった内容も書かれています。章タイトルや本文中でも多く言及されていますので、「オレはSREだ」という方々、知見を深める意味でも是非ご一読ください。

5. 上記以外の方

というか、この記事のタイトルを見て概要を読んでさらにここまで読み進めた方なら素質は十分です！
迷うことなくお買い求めくださって結構かと思います！

まだちょっと良く分からない、という慎重な方におかれましては、弊社吉井 ^*8による 真面目な 紹介記事もあがっておりますので、こちらも合わせてご参照下さい。 ^*9

目次

ここでは章タイトルまでを引用します。
節タイトルまで読むともっと内容がイメージしやすいと思うのですが、長くなるので。。。気になった方は、冒頭にも上げたこちらのページから、全目次を参照することができます。そちらをご参照ください。

• 第Ⅰ部　オブザーバビリティへの道
  • 1章　オブザーバビリティとは？
  • 2章　オブザーバビリティとモニタリングにおけるデバッグ方法の違い
  • 3章　オブザーバビリティを用いないスケーリングからの教訓
  • 4章　オブザーバビリティとDevOps、SRE、クラウドネイティブとの関連性
• 第Ⅱ部　オブザーバビリティの基礎
  • 5章　構造化イベントはオブザーバビリティの構成要素である
  • 6章　イベントをトレースにつなぐ
  • 7章　OpenTelemetryを使った計装
  • 8章　オブザーバビリティを実現するためのイベント解析
  • 9章　オブザーバビリティとモニタリングの関係
• 第Ⅲ部　チームのためのオブザーバビリティ
  • 10章　オブザーバビリティへの取り組みをチームへ適用する
  • 11章　オブザーバビリティ駆動開発
  • 12章　サービスレベル目標の信頼性向上への活用
  • 13章　SLOベースのアラートへの対応とデバッグ
  • 14章　オブザーバビリティとソフトウェアサプライチェーン
• 第Ⅳ部　大規模なオブザーバビリティ
  • 15章　投資収益性: 作るか、それとも買うか
  • 16章　効率的なデータストア
  • 17章　安価で十分な精度にするためのサンプリング戦略
  • 18章　パイプラインによるテレメトリー管理
• 第Ⅴ部　オブザーバビリティの文化を拡大する
  • 19章　オブザーバビリティのビジネス事例
  • 20章　オブザーバビリティの利害関係者と協力者
  • 21章　オブザーバビリティ成熟度モデル
  • 22章　ここからどこへ

また上に貼った山口氏の記事には「おすすめの読み方」なども書かれているのでこちらもお勧めです。

なお、たびたびふれられる名著「入門 監視」ですが、もしまだお読みでないという方がいましたら、弊社ハマコーによる殿堂入りの紹介記事がありますので、こちらも是非ご参照下さい。

「のっけから、刺激が強い。」のはこの手の本の伝統ですね！

まとめ

以上、感情過多でお話ししてしまいましたが、この業界に長い方も、そうでない方にとっても、「なるほど」と思うような事柄が満載の本です。ひとりでも多くの方に手に取ってもらえたら幸いです。純粋にそう思います。

それでは、楽しいオブザーバビリティライフを！

---

脚注